-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(GH<->GGs): Repair GGs #996
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left comments!
Do also add the new env var to the deploy script to fetch ssm params
fromPromise( | ||
this.reposService.setUpStagingLite( | ||
path.join(EFS_VOL_PATH_STAGING_LITE, repoName), | ||
repoUrl | ||
), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm actually does this assume that a staging lite doesn't exist? it seems to attempt a clone + pull, but we also want this to be able to repair error right, is this the desired behaviour?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually fair this not v clear, updated pr desc
We always assume staging lite doesnt exist. the reason why we dont git pull is because once we git pull, .git reconciles and the folder bloats, and we lose the benefits of a small bundle size. so we always reset, and this is not too long (< 1min for nlb iirc.
We also always clone and pull. the reason for this is because cloning takes time, with repos like nlb it can take a while, so we do a pull right before we reset staging lite.
It is notable that during this period of time, any changes to the repo will screw this repair up, but actually this is ok because:
- we can always re-run this script
- we are not rate-limited in any way for the above ^
): void => { | ||
const submission = this.formsg.crypto.decrypt( | ||
): Promise<void> => { | ||
const submission = await this.formsg.crypto.decryptWithAttachments( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do existing forms (without attachments) work with this? do we need a conditional on attachment existence?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, checked already
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait to be clear this was a breaking change to the api, so the other forms had to change and I checked that the other forms were able to parse the content (ie the individual fields)
Do also add the new env var to the deploy script to fetch ssm params |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
Problem
Pains:
This is also annoying since we need to go through a bunch of hops to enter into our efs in prod, which makes oncall a pain.
Rather than having separate scripts for each of this pain point, this form intends to kill 4 birds in one stone.
Solution
This formsg script is a idempotent script to be used when
addressing @alexanderleegs' comments at the PR desc level cuz its not v clear from just the code
We always assume staging lite doesnt exist. the reason why we dont git pull is because once we git pull, .git reconciles and the folder bloats, and we lose the benefits of a small bundle size. so we always reset, and this is not too long (< 1min for nlb iirc.
We also always clone and pull. the reason for this is because cloning takes time, with repos like nlb it can take a while, so we do a pull right before we reset staging lite.
It is notable that during this period of time, any changes to the repo will screw this repair up, but actually this is ok because:
Breaking Changes
Screenshots
Error state:
Success state:
Tests
// staging ssm stuff is not working.
Deploy Notes
New environment variables:
GGS_REPAIR_FORM_KEY
: Form secret keyfetch_ssm_parameters.sh
)New scripts:
script
: script detailsNew dependencies:
dependency
: dependency detailsNew dev dependencies:
dependency
: dependency details